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Abstract —Proximity-1 protocol has been the key in successful 
communication link establishment for a number of extraterres¬ 
trial missions. In recent years ISRO has flown missions to the 
moon and Mars. Given the reliability of Proximity-1 protocol 
over short distances, it was decided to develop the protocol for 
ISRO’s future space missions where a short haul communication 
link is required for communication between Rovers, Landers 
and Orbiters. In this paper we discuss the implementation 
of Proximity-1 protocol with reference to the requirement of 
Indian spacecrafts. The paper discusses the modifications and 
customization made during implementation of the protocol under 
the purview of protocol standard. Requirements and feasibility 
of new features such as proximity safe mode and data interface 
unit are discussed with possible scenarios which may employ 
them. The safe mode allows usage of all proximity features, but 
with a greater protocol control and reduced complexity. Data 
interface unit allows proximity to function as independent module 
and communicate with higher layers via high speed interfaces. 
The paper details the response to directives and generation of 
notifications at various sublayers of the protocol. The protocol 
is developed and tested on an FPGA platform. Test setup and 
testing strategies used to evaluate the performance of the protocol 
at baseband level are also discussed. 

Index Terms - CCSDS, Proximity-1, Protocol, Space link, 
Data service, sequence controlled, hailing, data link layer 

I. Introduction 

Proximity-1 protocol standard, given by Consultative Com¬ 
mittee for Space Data Systems(CCSDS) provides a link stan¬ 
dard for short-range, bi-directional, fixed or mobile radio 
links, generally used to communicate among probes, Landers, 
Rovers, orbiting constellations, and orbiting relays [1]. The 
protocol was conceived during a brainstorming meeting at 
JPL in 1998 where the experts wanted a protocol which 
can maximize data collection and improve the reliability of 
the link to guarantee delivery of data without any errors for 
NASA’s Mars missions [4]. The protocol was based upon the 
CCSDS Telecommand protocol [5] with addition to a go- 
back N feature and auto repeat queueing(ARQ) to increase 
the throughput compared to simpler stop and wait protocols. 
CCSDS released the first version of Proximity-1 protocol in 
form of a blue book on October 2002 and since then there had 
been 4 revisions of the protocol with the latest one released 
on December 2013. Since its release majority of Mars bound 
missions have successfully implemented and used Proximity-1 
protocol to relay data from rovers/Landers. 

Proximity-1 is a link based communication protocol in 
which a session between the two terminals should be estab¬ 
lished before the data communication can be initiated. The 


process of session establishment is known as hailing. The 
protocol employs a layer based approach like IP but with lot 
more interaction and control of layers by the application/user 
via Medium Access Control (MAC) sublayer to increase 
the reliability. The protocol’s rate change feature allows the 
user to configure the protocol according to the link margin 
by dynamically changing the communication rate during the 
session. The protocol provides the user with a reliable and 
a non reliable but fast data service. The auto repeat queuing 
(ARQ) with a go-back-N feature of the reliable service (known 
as sequence controlled service) retransmits the frames in auto 
mode till their delivery acknowledgement is received hence 
increasing the reliability as well as throughput of the data 
service. 

The protocol supports communication in broadcast and 
point to point communication with option for simplex, half du¬ 
plex and full duplex mode. CCSDS have issued three standard 
dealing with data link layer [1], coding and synchronization 
sublayer (part of data link layer) [2] and physical layer [3] 
of the protocol. In this paper our implementation of data link 
layer is focused on point to point communication in full duplex 
mode. A typical application for such configuration is commu¬ 
nication between an orbiter and a rover. Implementation focus 
is on customization of the protocol within the scope of the 
CCSDS standard to ensure the implementation benefits as well 
as cross-agency interoperability. Apart from customization, 
new features are included in the protocol implementation. To 
allow protocol to interface with users using high speed serial 
interfaces, a Data Interface Unit (DIU) has been proposed. 
DIU can support multiple communication standards that can 
be selected upon need, providing the protocol a more modular 
approach. Introduction of a Proximity- safe mode allows 
user/Vehicle controller to take on the full control of the 
protocol in case of a link contingency. The feature enables the 
vehicle controller to use all the proximity modules as required. 

The rest of the paper is divided into 5 sections. Section 
2 will briefly review the protocol standard and outline the 
customizable areas identified by the authors. Section 3 focuses 
on FPGA implementation of the protocol and discuss the 
variation/customizations made within the protocol standard’s 
domain. Section 4 will introduce the new features proposed 
for the protocol. Section 5 will describe the testing procedure 
used while the paper concludes in section 6. 


978-l-4799-3080-7/14/$31.00 ©2014 IEEE 


2813 


II. Proximity- 1 review 


TABLE I 

Proximity state variables 


This section reviews Proximity-1 protocol’s data link layer, 
highlighting the areas in the protocol that can be tuned 
according to the implementation requirement. The section only 
provides cursory review and it is advised to refer CCSDS 
document on proximity-1 Data link layer [1]. Function of 
each sublayer is explained followed by the customization fields 
identified within the sublayer. 

CCSDS divides data link layer of Proximity-1 protocol 
into five sublayers according to their functionality. Figure 
(1) shows the structure of these sublayers as defined in the 
protocol standard [1]. The first layer in proximity-1 data 
flow is Input/Output sublayer. This sublayer is responsible 
for reception of data from the user. In this paper user is 
referred to any application that employs proximity-1 to send 
and receive data. The implementation focus is on deciding 
the data interface with the user, customizing control signals 
such as Quality of Service(QOS), Port ID, flow control etc. 
and formatting frame by aggregating parameters in the 5 byte 
proximity header. 



Fig. 1. CCSDS standard Proximity-1 Data link layer 

Next in data flow is data services sublayer. Proximity-1 sup¬ 
ports two data services viz. sequence controlled and expedited 
service, providing a reliable and an unreliable but simpler 
data service to user respectively. Data services sublayer is 
responsible for managing these data services. Implementation 
focus include managing frame storage for either services, 
maintaining the Communication operation procedure (COP) 
State variables [1], generation and reception of Proximity link 
control word (PLCW), taking action on clear queue directive, 
deciding on when to raise resync flag, reaching the optimum 
queue length, managing/implementing queue mechanism and 
retransmission logic. List of state variables referred in this 
paper is presented in table I. The implementation should also 
decide whether to provide all these features in Data services 
sublayer or relegate them to other sublayers. 

Further in the data flow is frame sublayer, whose major 
responsibility is implementation of priority logic for selection 



Variable 

Description 

1 . 

V(E) 

Sequence number of next Expedited frame to be sent. 

2. 

V(S) 

Sequence number of the next new Sequence Controlled 
frame to be sent. 

3. 

VV(s) 

Sequence number to be assigned to the next 

Sequence Controlled frame to be sent. 

4. 

NCR) 

Copy of the Report Value from the current PLCW. 

5. 

NN(R) 

Copy of the Report Value from the previous valid PLCW. 

6. 

V(R) 

Sequence number plus one of the last Sequence Controlled 
frame acknowledged by the receiver 

7. 

N(S) 

Sequence number contained in the transfer frame header 
of the received Proximity-1 Frame 


of frame. This logic is very well defined by the CCSDS docu¬ 
ment. Still the implementation grey areas include generation of 
PLCW and status reports and relaying data to lower sublayers. 

The last sublayer in data flow structure in Proximity-1 pro¬ 
tocol’s data link layer is coding and synchronisation sublayer. 
True to its name, the major task of the sublayer is providing 
platform for synchronization and coding/decoding of frames. 
The sublayer has only a few fill-ups for implementation in the 
form of providing output clock, generating notification upon 
radiation of frame and time tags. Since the focus of this paper 
is data service implementation, timetags will not be discussed. 

Medium Access Control (MAC) sublayer is not the part 
of data flow, but nonetheless produces supervisory frames 
(SPDU) which are transported to the remote terminal via 
proximity-1 channel. The sublayer generates control signals 
responsible for session establishment, control/communication 
parameter change, resynchronization, link upkeep and session 
termination . Implementation issues include resynchronization 
process, local and remote directive decoders and deciding 
interface with local vehicle controller. Deciding mode of 
operation(duplex, simplex etc.)and communication parameters 
are management decisions taken based on user requirements. 

The receive functionality of the four layers involved in 
data flow as shown in figure (1) is limited compared to 
their send functionality. Therefore for implementation all 
these functionalities are clubbed into one module referred as 
receive unit. The implementation issue remains deciding what 
functionalities should be combined, distribution of frames to 
various layers and user frame port management. 

Data interface unit (DIU) shown in figure (2) is not the 
part of protocol standard and hence is not shown in figure(l). 
The purpose of this module is to provide selectable interfaces 
between proximity and the user. DIU increases the modularity 
and ease of implementation for the protocol as the required 
interface can be selected from DIU. Another new feature of 
proximity safe mode is also presented in implementation. This 
feature do not require a separate unit and is only an addition 
to the standard. 

III. Protocol implementation 
A. I/O Sublayer 

I/O sublayer receives serial data, clock and a data qualifier 
window line from the user. User also provides I/O layer 
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with QOS signal to decide the quality of service and Output 
port ID as these parameters can change dynamically. Other 
inputs such as Remote Spacecraft ID, Source or destination 
identifier are provided by MAC sublayer and are changed by 
issuing local directives. The segregation of input parameters 
for frame header formation is done on based of relative static 
and dynamic nature of the parameters and to avoid multiple 
interface of vehicle controller with proximity-1 unit. The I/O 
sublayer provides user with two flow control signals one for 
each of the two data services. This allows user to employ 
expedited data service if sequence controlled queue is full and 
vice versa. 



Fig. 2. Proximity-1 Data link layer implementation 


The user is not expected to generate a supervisory protocol 
data unit (SPDU) and hence PDU type is not taken as input 
from the user. Instead SPDUs are generated by MAC layer and 
generation of all the SPDUs are controlled by local directives. 
In our application, the controlling body and intelligence sits 
entirely with local vehicle controller which interacts with 
MAC layer as shown in figure (1). Hence notification of frame 
generation and delivery are not generated by I/O sublayer. In¬ 
stead all the notifications are generated by MAC sublayer and 
are transferred to local vehicle controller for processing and 
decision making.In our implementation I/O sublayer maintains 
the frame sequence variable V(S) and frame header is also 
formed and stored in memory along with the user data at I/O 
sublayer. This task reduces the complexity of reforming header 
during retransmission. 

The state diagram shown in figure (3) shows the three basic 
states in functionality of I/O sublayer. I/O sublayer maintains 
two such state machines for independently servicing data 
frames with different quality of service. Data is transferred 
to Data services sublayer if the sublayer is ready to receive 
the frame of particular data service. 

B. Data Service Sublayer 

Data services sublayer(DSS) contains two modules, each 
dedicated to either of the data services. User data along with 
frame header is received and stored in a memory queue by 



Fig. 3. state transition diagram for I/O sublayer 

the Data Services sublayer. The queue length for sequence 
controlled service is calculated based on maximum number 
of back to back frames that can be sent out before a valid 
PLOW is expected. For this calculation, following parameters 
are assumed. 

Distance : D (max). 

Frame Size : 2048 bytes(max). 

Data rate : Rd kbps (max). 

From these specifications, one way time (OWT) for the 
frame maybe calculated as 

OWT = D/C. (1) 

Where C is speed of light in vacuum. 

For worst case calculation, lets assume that when a frame 
arrives at reception node of proximity, it has already begun 
transmission of its own frame. Therefore till transmission of 
the frame is not completed, PLCW cannot be transmitted. The 
transmission delay (Td) will be given by 

Td = 2048 * 8/Rd. (2) 

Adding this delay to the total time, we get total 
delay (T Delay ) as 

T De i a y = 20WT + Td (3) 

Finally, dividing total delay by transmission time and round¬ 
ing it off to next higher integer gives us queue length(Qu). 

Qu = T De i ay /Td (4) 

For example if we select maximum range supported by 
proximity (100,000 km) and bit rate as 64 Kbps we obtain 
optimum value of ‘Qu’ as 4. 

Expedited service module in Data services sublayer perform 
a simple function of accepting frame from I/O sublayer and 
forwarding it to Coding and synchronization sublayer(CSS) 
based on signal from frame sublayer. Sequence controlled 
service module on the other hand involves more complex 
operation of implementing FOP (Frame operations Procedure) 
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and FARM ( Frame Acceptance and Reporting Mechanism) 
operations [1]. 

Frame received from I/O layers is stored in memory and 
transmitted to CSS before another frame is accepted. As shown 
in state diagram of figure (4), default state is selection state. 
First priority is given to a retransmission request received 
via PLCW. Second priority is assigned to acceptance and 
transmission of new frame. Last priority is given to initiate a 
progressive retransmission. Once retransmission flag is high, 
all the unacknowledged frames in the queue are retransmitted. 
Variable ‘num_of_frames’ contains difference of V(S) and 
N(R) and will indicate how many frames are to be transmitted. 
When in transmission state, this variable is reduced by one 
each time a frame is transmitted. When ‘num_of_frames’ 
becomes zero, state is changed to selection again. Two modulo 
‘Qu’ memory pointers are used to make the usage of memory 
queue cyclic. These pointers are M_old and M_next which 
point to the oldest unacknowledged and the next memory 
location for frame storage respectively. 

For FARM operation, the PLCW is received from ‘Receive 
Unit’ and is validated according to standard. The frames are 
acknowledged by incrementing M_old, N(R)-NN(R) times. 
PLCW generation being simple operation is implemented 
in frame sublayer. Whenever a valid PLCW arrives, MAC 
sublayer is signalled to generate a notification to Vehicle 
controller giving information about the frame successfully 
delivered. 



Fig. 4. Sequence controlled logic. 


For resync operation, resync timer is present in the DSS 
which expires if no PLCW is received within a particular dura¬ 
tion which is an integer multiple of ‘PLCW_Repeat_Interval’. 
These intervals are calculated proportional to the expected 
FER (Frame Error Rate) for the desired link environment. 
If DSS contains no unacknowledged frames, resync timer is 
disabled. If MAC sublayer’s resync process fails, a clear queue 
directive is issued Clear queue directive makes M_next equal 
to M_old and V(S) is made equal to NN(R)+1 value. 


C. Frame Sublayer 

Frame sublayer employs a priority logic to select between 
SPDU from MAC sublayer, expedited and sequence controlled 
frames generated at DSS and PLCW/Status report. PLCW is 
generated within frame sublayer on cue from the Receive Unit. 
PLCW repeat timer which enables generation of PLCW at 
regular interval is also implemented with the frame sublayer. 
Status reports are also generated within Frame sublayer and 
are treated as SPDUs. 

D. Coding and Synchronization Sublayer 

Coding and synchronization sublayer(CSS) collects data 
from different sublayers via Frame sublayer and calculates 
32 bit cyclic redundancy check(CRC) [2] . After prefixing 
the frame with an attached synchronous marker(ASM) the 
frame and CRC is coded and radiated. Frame radiated signal 
is generated by CSS and given to MAC sublayer for formation 
of a notification to the user. This notification is useful when 
using expedited service as there is no delivery notification for 
expedited service.. 

E. Receive Unit 



Fig. 5. Receive Module state diagram. 


For ease of implementation, the receive functionality of all 
the sublayers as shown in figure (1) is implemented in the 
Receive Unit. The unit receives data from a decoder (Viterbi 
decoder). The default state of the unit’s state machine shown in 
figure (5) is frame search state. In this state, the receive unit 
searches for ASM. Given the possibility of phase inversion 
in BPSK, both ASM and its bit inverse are searched. If 
the inverse of ASM is detected, all the subsequent bits are 
inverted. This method allows solving phase inversion without 
use of differential encoding. Upon detection of ASM, the 
frame is inspected for Spacecraft ID, Version number and CRC 
related errors. Valid frames are segregated into SPDUs and 
user frame. SPDUs are further checked if they are PLCW or 
not. PLCWs are transferred to DSS while other SPDUs are 
transferred to MAC sublayer. User frames are again checked 
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for their quality of service. Expedited frames are transferred 
to user without any further checks through appropriate user 
port while sequence controlled frames are checked for in¬ 
sequence arrival by comparing N(S) with V(R). For a frame 
to be valid, its N(S) should be equal to V(R) value of the 
receiver module. If N(S) is less than V(R), it denotes that 
the received frame is repetition of an already acknowledged 
frame. This condition can arise if the PLCW for the frame was 
lost. A fresh PLCW can be issued under this circumstance to 
avoid unnecessary retransmission of frames under progressive 
retransmission mechanism. If N(S) is grater than V(R) it 
denotes a gap in sequence that may arrive due to sequence 
control frame loss. Under such condition a PLCW is sent 
with retransmission bit set to high. Valid frames are forwarded 
to user at requested virtual output port while invalid frames 
are rejected. In both cases frame sublayer is signalled for 
generation of PLCW with appropriate setting of retransmission 
flag. 

Combining all these operations in one unit eases up im¬ 
plementation and reduces interlayer connections. Receive unit 
provides MAC sublayer with notifications about frame error 
and its type along with V(R) value which is used in ‘set V(R)’ 
directive and resync process. 



Fig. 6. Receive Module. 


TABLE II 
Notifications 



Notification 

Description 

1 . 

Hail success 

Report that link is successfully 
established. 

2. 

Hail failure 

Report that attempt to establish link was 
unsuccessful. 

3*. 

Directive rejected 

Report the reason why local directive was 
rejected. 

4. 

Carrier detect only 

Report that carrier only was detected 
after the Wait for Hail 

Response state terminated. 

5. 

Carrier lost 

Report that carrier loss timer has 
expired. 

6*. 

Configuration change 

Report that a control or communication 
parameter was changed. 

7. 

Sync timer expired 

Report that a valid PLCW is not 
received in specified duration 

8. 

Resync failed 

Report that attempt to Resync has failed. 

9*. 

Set V(R) requested 

Report either Set V(R) request was 
generated or received. 

10*. 

Status report requested 

Report when status report generated, 
requested or received. 

11*. 

RNMD requested 

Report that Remote terminal have 
no more data to send 

12*. 

PLTU Radiated 

Report when an expedited PLTU 
was radiated. 

13*. 

PLTU Delivered 

Report when a sequence controlled 
frame was delivered. 

14. 

Frame error 

Report when a frame arrives with either 
Space craft ID, version ID or CRC error. 

15. 

State variable status 

Report the State variable 
status upon request. 

16. 

Timing services 

Report about status and roundtrip time 
calculation for timing services. 

17*. 

Session terminated 

Reports when a session is terminated. 


directive decoder receives, decodes and executes these SPDUs. 
Apart from directives specified in the standard, new directives 
for status report and set V(R) are included. Various timers who 
take their value from Management information base(MIB) are 
also maintained by MAC sublayer. These timers include Hail 
wait timer, Carrier only duration, carrier in-lock timer, tail 
duration and hail attempt lifetime. MAC sublayer also provides 
static informations such as SCID and source or destination 
mode to I/O sublayer. 


F. MAC Sublayer 

MAC sublayer interfaces all sublayers in data link layer and 
physical layer with local vehicle controller. Commands are 
issued to MAC sublayer in form of Local directives which are 
decoded and executed by local directive decoder as shown in 
figure (7). Along with the directives mentioned in the standard 
[1], new directives are also added to change the static param¬ 
eters such as space craft ID, Source or destination parameter 
and PDU type. Directives to issue a set V(R) command and 
ask for status report is also included. Notifications for various 
events are provided to the local vehicle controller to take 
necessary action. List of these notifications is provided in 
table (II) with new notifications marked with a 4 *’ mark. MAC 
sublayer also issues remote directives which are transmitted 
to remote proximity terminal in form of SPDUs. A Remote 


-- Vehicle Controller 



Fig. 7. Medium Access Control Sublayer 
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MAC sublayer executes task such as establishment of 
session, termination of session, acquisition of status reports 
and Resync operations. Resync flag is raised by DSS and 
in response, MAC layer sets the persistence flag to frame 
sublayer. During persistence only MAC SPDUs are allowed 
to be radiated and user frames are not allowed service. 
MAC sublayer copies NN(R) from DSS and issues set V(R) 
command. As a response to set V(R) command, MAC sublayer 
receives a status report. IF the report value of status report, 
which contains V(R) value of the remote terminal is found 
equal to NN(R) of local terminal, normal operation is resumed. 
But if satisfactory report is not received within stipulated time, 
a clear queue directive is issued to I/O sublayer and DSS which 
clears all the unacknowledged frames in the queue. Also, a 
notification is issued to user to take a decision on quality of 
service for further frames within the given session. 


IV. New features 
A. Proximity Safe Mode 

Proximity Safe mode is a feature that allows usage of 
proximity modules in a manual mode. Though proximity-1 
protocol is highly reliable protocol, but if due to some un¬ 
foreseen conditions, protocol is not able to establish a session 
automatically, the hail procedure of link establishment can be 
bypassed by using the proximity safe mode. Proximity Safe 
mode allows Local vehicle controller to control all the protocol 
modules, send and receive remote directives and User data. 
To enable this feature, the Receive Unit is kept operational in 
all modes. To bypass hail procedure, Local vehicle controller 
issues a ‘Set mode’ local directive to MAC sublayer, which 
forcefully set the protocol mode to active and allows usage 
of data service. Further using the data service, commands can 
be sent to the vehicle controller of remote Proximity unit to 
issue a similar bypass command to the proximity protocol 
unit at remote terminal and allow data flow from remote to 
local terminal. Preferred data service during this operation 
is expedited although sequence controlled service can also 
be used. The Safe mode also allows SPDUs to be sent via 
data path by forcing PDU type identifier issued by the MAC 
sublayer to the I/O sublayer to one. 

The safe mode can be used when the devices other than 
the proximity module fails to perform. A typical example 
involves demodulator failing to provide a carrier or symbol 
lock status. In such case, proximity will not be able to establish 
the connection automatically. The user can then try sending 
data/ commands to the remote terminal using proximity safe 
mode and if a response is received, continue in safe mode. 
The safe mode also proves useful if the carrier in the link is 
erratic. In such case, the session will be abruptly terminated 
each time the carrier in-lock timer expires. The advantage of 
proximity safe mode is that it does not totally bypasses the 
protocol but only allows user more control over the protocol 
modules. 


B. Data Interface Unit 

Data Interface unit(DIU) is customizable hardware unit that 
acts as an interface between Proximity protocol unit, the 
user and local vehicle controller. The unit has relevance at 
implementation level. Depending on the spacecraft employing 
proximity protocol, interface of protocol with user can be 
through different standard interfaces such as serial port RS232, 
Mil STD 1553 , space wire etc. To make proximity more 
modular in such case, data interface unit is used. The unit 
contains selectable interfaces that connects proximity to user 
and local vehicle controller. The DIU shown in figure (2) 
performs the function of receiving and sending data from 
proximity unit and convert it into selected interface’s packet 
format. For testing purpose, DIU implemented in figure (2) 
contains a RS232 transceiver, local storage unit and a packet 
decoder. Packet decoder decodes the packet and transfers the 
frame to proximity in the standard format. Decoder also set 
the control signals according to the information in the packet. 
DIU’s focus is on providing high speed interface with user 
and provide data and control signals to proximity unit such 
that DIU is the only variable unit when design is ported from 
one spacecraft to other. 


V. Testing 

To test implementation of Proximity-1 protocol, a test set 
up shown in figure (8) was used. The test set up contains two 
proximity nodes implemented on Xilinx Virtex-4 FPGA. Other 
systems such as user and vehicle controller were simulated 
using separate PC for each proximity node. Commands and 
data were communicated to FPGA via a serial interface and 
were converted to standard interface by the Data Interface Unit 
as shown in figure (2). The data exchanged between the two 
nodes was tapped by a monitoring module which receives all 
the data and store/display the frames on another PC for manual 
validation. Switches were used on all the data lines to simulate 
various link disruption contingencies . 


Link monitor 
PC Display and 
storage 

n Serial 
Comm, port 



Orbiter 

PC 

Simulator 


Transmit and modulate 


Carrier and Bit detect 


Fig. 8. Test Setup for Proximity-1 Validation 


The set up was used to test following features of the 
protocol. 

Hailing and session establishment 
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Expedited services operations. 

Sequence controlled service operations. 

Normal termination. 

Forced termination. 

Verification of directives and notifications. 

Verification of priority for frames. 

Synch time-out conditions. 

CRC errors by manipulating switches 
Proximity safe mode operations. 

All the tests were carried out for extended duration as well 
as shorter durations with data transfer carried out over multiple 
sessions 


VI. Conclusion 

In this paper, we have reviewed CCSDS proximity-1 pro¬ 
tocol. Implementation for different sublayers of the data 
link layer is discussed and customizations made to standard 
protocol were highlighted along with their implementation 
advantages. New features of proximity safe mode and data 
interface unit were discussed with advantage of using these 
features clearly justified. The protocol was tested and verified 
on Xilinx Virtex -4 FX60 and Actel ProASIC AP3E3000 
FPGAs according to the test setup described in testing sec¬ 
tion. All new, modified and standard features of the protocol 
performed as per expectations. The configuration is targetted 
for ISRO’s future extraterrestrial missions. 
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